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Introduction 


The  KiaCHO  (Mouie  and  Cartouches  for  Handling  Objects)  Interface,  or  MaCHO-I  for 
short,  is  designed  to  be  the  primary  application  independent  user  interface  for  the 
SMITE  secure  capability  computer  fTerrySS,  WisemanSSa,  WisemanSSb,  WisemanSScI. 
This  document  formally  describes  the  salient  features  of  MaCHO-I  in  the  notation  of 
Z,  a  specification  language  based  on  the  mathematics  of  typed  set  theory  developed 
by  the  Programming  Research  Group  at  Oxford  University.  The  reader  who  is 
unfamiliar  with  Z  is  advised  to  read,  or  at  least  have  available  for  consultation,  the 
many  good  reference  annuals  available  on  the  language  ISufrinSb,  SpiveySSl  before 
embarking  on  the  rest  of  this  paper. 

MaCHO'I  is  strongly  based  on  the  interface  of  the  Flex  computer  [Foster82l,  in 
particular  in  its  use  of  the  graphical  block  (henceforth  referred  to  as  the  gblock)  as 
a  fundamental  data  object.  As  its  naate  suggests,  this  data  structure  is  one  that  is 
directly  representable  graphically  on  the  display  screen  and  which  is  composed  of  a 
set  of  objects  grouped  together  to  form  a  whole.  Gblocks  can  thus  take  on  many  forms 
of  varying  sizes  but,  more  importantly,  they  can  contain  other  gblocks  in  their  object 
set.  For  instance,  if  we  view  a  line  of  characters  as  a  gblock  then  several  lines  may 
be  combined  to  form  a  gblock  called  a  paragraph;  similarly,  several  paragraphs  may 
make  a  page.  (For  more  on  the  uses  of  gblocks  see  (Core871.) 

Whilst  both  the  MaCHO  and  Flex  interfaces  are  founded  upon  gblocks,  it  is 
important  to  note  that  the  former,  MaCHO-I,  can  neither  manipulate  them  to  such  a 
great  extent  as  the  latter,  nor  does  it  even  recognise  the  full  spectrum  of  types  of 
gblock  that  Flex  does  (approximately  two  thirds  are  not  present).  However,  despite 
this  reduced  functionality,  the  MaCHO  Interface  is  being  constructed  to  be  superior  to 
its  Flex  counterpart  in  possessing  those  properties  that  are  of  overriding  concern  in 
the  environment  of  the  SMITE  project  -  complete  trustworthiness  and  total 
correctness. 

To  describe  the  design  of  MaCHO-I  in  a  clearly  comprehensible  manner,  this 
document  has  been  split  into  a  number  of  discrete  sections.  Section  1  is  concerned 
with  an  informal  description  of  gblocks  and  other  data  structures  as  they  are  used  in 
MaCHO'I.  Sections  2  and  3  formalise,  in  Z,  the  notions  of  Section  1  and  also 
introduce  $ome  operators  to  process  them.  Section  4  defines  those  functions  which  are 
available  to  the  user  whose  effects  on  the  various  data  structures  of  the  interface  are 
specified  in  sections  7  through  to  20.  Section  5  deals  with  those  aspects  of  the 
interface  associated  with  defining  views  of  the  data  by  windows  and  section  6  defines 
those  simple  schemas  which  are  not  constrained  to  be  used  in  conjunction  with  any 
one  particular  function  but  rather  with  many  spread  through  the  text. 
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SactloB  1;  Dwcriptloo  of  lifaCHO-I  Data  Stnicturt 


The  display  of  the  MaCHO  Interface  (i^.  what  the  user  sees  on  the  screen)  is,  at 
first  glance,  very  simple  -  to  the  user  it  appears  as  a  (mostly)  blank  space  over  which 
they  can  reposition  and  type  text  at  will.  To  select  a  point  on  the  screen  for  the 
cursor  requires  a  simple  movement  of  the  mouse  over  a  tablet. 

Of  course,  the  real  situation  is  much  more  complicated.  Firstly,  the  display  is 
composed  of  many  non-overlapping  gblocks  that  can  be  selected  by  the  mouse,  usually 
together  with  several  void  portions  of  the  screen,  that  is,  areas  which  are  not 
covered  by  any  part  of  a  gblock  and  can  NOT  be  selected  by  the  mouse.  Secondly,  the 
position  of  the  mouse  on  the  tablet  does  not  necessarily  bear  any  relation  to  the 
displayed  cursor  -  the  system  which  reads  and  interprets  the  location  of  the  mouse  is 
entirely  seperate  to  that  which  displays  the  cursor.  This  means  that  one  of  either  the 
cursor  or  the  mouse  can  be  moved  without  affecting  the  other.  At  all  times  though, 
the  absolute  position  of  the  mouse  on  the  tablet  is  conveyed  to  the  user  via  a  small 
arrow,  known  as  a  pointer,  drawn  on  the  screen. 

In  MaCHO-I  there  are  four  distinct  types  of  gblock: 

•  the  line 

•  the  vervec 

•  the  horvec 

•  the  cartouche 

We  will  examine  each  of  these  types  of  gblock  in  turn  and  describe  their 
representation  in  the  explanatory  diagrams  to  be  used  throughout  the  remainder  of 
this  text. 

Line 

A  line  is  a  simple  sequence  of  characters,  as  may  be  expected.  The  gblock 
containing  this  sequence  will  be  represented  as  the  string  enclosed  by  double 
quotes  e.g.  "Hello  Everybody". 

Vervec 

A  vervec  is  a  vertical  vector  of  gblocks  and  so,  for  instance,  one  line  atop 
another  constitutes  a  vervec.  Vervecs  notionally  run  from  the  top  of  the  page 
or  screen  to  the  bottom  and  so  in  all  diagrams,  a  vervec  will  be  shown  as  a 
series  of  rectangles  with  this  orientation: 


"Hello  Everybody" 


Fipire  1:  An  Example  Vervec 


Figure  1  shows  a  vervec  whose  third  element  is  a  line  type  gblock 
containing  the  string  "Hello  Everybody";  the  contents  of  the  other  elements  in 
the  vervec  are  not  specified.  Note  that  the  elements  of  the  vervec  align  at 
their  leftmost  edge. 


HorvecT 

A  horvec  is  a  horizontal  vector  of  gUocks  which  notionally  runs  from  left  to 
right  on  the  screen.  For  instance,  three  vervecs  alongside  each  other  would 
constitute  a  horvec.  In  a  fashion  similar  to  that  for  vervecs.  horvecs  are  drawn 
as  a  sequence  of  rectangles  in  the  appropriate  orientation: 


"Hello  Everybody"! 


Figure  2:  An  Bxassple  Horvec 

Again,  we  notice  an  important  alignment  property:  the  gblocks  of  a  horvec 
sdign  at  their  topmost  points. 


(The  reader  should  note  that  the  rectangles  in  the  diagrams  for  horvecs  and 
vervecs  are  for  the  purposes  of  illustration  only  -  they  do  not  appear  in  the  actual 
display  of  MaCHO-I.I 

Cartouche 

Of  the  four  types  of  gblock  in  MaCHO-I  .  the  cartouche  is  by  far  the  most 
difficult  structure  to  describe  in  simple  terms.  Perhaps  surprisingly,  however, 
we  can  gain  some  sort  of  understanding  from  Chambers  20th  Century  Dictionary 
which  describes  a  cartouche  as  ‘an  ornamental  form  for  receiving  an 
inscription":  in  MaCHO-I  we  view  the  cartouche  as  a  visible  representation  of  a 
capability  (in  the  computing  sense  of  (Fabry 741)  which  can  take  the  form  of  a 
picture  or  just  simple  text. 


In  its  (less  common)  pictorial  form,  a  cartouche  is  akin  to  the  well  known 
notion  of  an  icon  on  such  machines  as  the  Apple  Macintosh;  in  its  textual  form 
it  resembles  a  file  name.  Whatever  form  they  take  though,  cartouches  in 
MaCHO-I  are  always  displayed  as  being  enclosed  by  a  rectangular  border  so 
that  they  can  be  easily  distinguished  from  ordinary  text  or  pictures.  For 
instance,  |centre  text  :M<^le]  is  a  cartouche  representing  the  capability  to  a 
file  containing  the  (compiled)  source  code  of  a  program  to  centre  text,  whereas 
_  may  be  a  user  defined  cartouche  of  the  capability  to  a  file  holding 


Olympic  Games  records.  To  actually  access  the  underlying  files  (through  their 
capabilities),  certain  operations  can  be  directly  applied  to  the  cartouches 
themselves.  In  subsequent  diagrams,  we  will  represent  cartouches  as  'lozenges', 
possibly  containing  text  within: 


Before  ending  this  description  of  cartouches,  it  should  be  pointed  out  that  in 
the  following  specification  we  make  no  mention  of  their  special  properties  •  we 
regard  them  only  as  another  type  of  gblock  to  be  handled  by  the  interface. 
Such  treatment  is  sufficient  for  the  purposes  of  this  document. 


Although  appearing  very  basic,  the  above  four  types  of  gblock  can  be  combined  to 
form  remarkably  complex  structures: 
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'^This_isjLiin;_r_bsl5M_li_S_S8Ctouch«^ 
lompilcr  :Fil«) 


Pl|itr«  3:  A  typical  (Biplay  in  llaCHO-1 

Figure  3  (above)  shows  a  three  elenent  vervec.  The  first  gblock  in  ttiis  vervec  is 
of  horvec  type,  the  second  is  a  line  and  the  third  is  a  cartouche.  In  turn,  the  horvec 
is  composed  of  two  vervecs,  both  of  which  are  made  entirety  from  line  type  gblocks. 
Those  parts  of  the  diagram  that  are  shown  in  Mack  represent  void  portions  of  the 
screen  inasmuch  as  any  attempt  to  point  to  these  regions  (using  the  mouse)  will  be 
disallowed.  Regions  of  this  nature  arise  due  to  the  disparity  of  the  sires  of  the 
gblocks  in  the  display.  In  this  example,  the  horvec  contains  such  a  void  region  due  to 
the  fact  that  one  of  its  elementary  gblocks  is  four  lines  Tong*  and  the  other  is  only 
three.  Those  re^ons  that  are  shown  'cross-hatched*  are  areas  of  the  screen  which, 
although  not  visibly  covered  by  any  objects,  are  considered  to  be  full  of  space 
characters  and  so  they  can  be  selected  by  the  mouse.  The  effect  pointing  to  these 
regions  depends  on  the  gblock  that  is  on  their  immediate  left  -  see  section  £ 

There  are  three  further  features  of  MaCHO-I,  each  of  which  plays  an  important 
part  in  creating  and  maintaining  tht  useability  of  the  interface: 

•  a  coordinate  system 

•  a  variable  sized  cursor 

•  a  stack  of  remembered  elements. 

Coordinate  System 

The  display  screen  has  a  coordinate  system  such  t)tat  the  origin  (0,0)  is  at 
the  top  left  hand  corner.  From  this  point,  coordinates  in  the  x  direction 
increase  to  the  right;  those  in  the  y  direction  increase  downwards,  towards  the 
bottom  of  the  screen.  Thus  all  valid  screen  positions  are  represented  by  a  pair 
of  positive  numbers.  We  use  this  coordinate  system  to  determine  which  gblock 
has  been  selected  by  pointing  operations  and  where  gblocks  are  displayed.  The 
outermost  gblock,  which  represents  the  entire  screen,  obviously  has  its  top  left 
corner  at  (0,0). 

The  Cursor 

In  the  MaCHO  Interface,  the  size  of  the  cursor  shrinks  and  grows 
dynamically  according  to  the  requirements  of  the  user  (but  it  cannot  become 
larger  than  the  screen  nor  can  it  contract  to  be  smaller  than  a  single 
character).  At  all  times,  the  objects  currently  covered  by  the  cursor  are 
displayed  in  reverse  video  format  and  so  if  the  cursor  were  covering  the  letter 
'a'  say,  then  the  user  would  see  a  white  *a*  against  a  dark  background.  In  most 
instances,  the  cursor  does  just  cover  one  single  character;  however,  it  is 
possible  to  group  gblocks  together  to  form  one  large  cursor  to  show  for 
instance  several  lines  in  reverse  video.  It  is  this  grouping  mechanism  that  allows 
us  to  delete  objects  covering  significant  portions  of  the  screen  in  one  keystroke 
(cf.  "Remembered  Elements*  below). 

Remembered  Elements 

This  is  a  data  structure  which  holds  all  the  gblocks  tltat  the  user  has 
deleted  from  the  screen  by  one  method  or  another  during  the  session.  The  most 
recently  deleted  gblock  is  at  the  top  of  the  stack.  At  any  time,  this  topmost 
gblock  can  be  reinserted  into  the  ^splay  at  t)ie  place  of  the  current  cursor 
(see  "The  Cursor"  above)  and  so  removed  from  the  remembered  elements.  Such  a 
scheme  gives  the  user  considerable  "cut  and  paste*  power  since  gblocks  can  be 
repeatedly  put  on  and  taken  off  the  stack  until  the  desired  display  is  achieved. 

As  a  method  of  communicating  the  state  of  the  remembered  elements  to  the  user, 
a  message  is  shown  giving  the  number  of  elements  on  the  stack  (but  not  what  is 
actually  in  it). 
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This  concludes  our  informal  description  of  the  MaCHO  Interface  and  its  data 
structures.  Despite  the  brevity  of  the  preceding  discussion,  it  is  hoped  that  more  of 
the  manipulative  properties  of  MaCHO-I  will  become  apparent  to  the  reader  from  the 
formal  specification  to  follow. 


SacttoB  2s  gor— 1  SptiflotloB  of  MaCHO-I  D«t«  Stnicturt 
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I  [GBLOCKl 

We  introduce  the  set  [GBLOCKl  which  contains  every  gbiock  that  can  possibly  be 
represented  in  MaCHO-I.  This  set  is  very  large,  despite  the  fact  that,  as  stated  in 
Section  1,  there  are  only  four  distinct  types  of  gbiock  t  we  shall  see  why  presently. 

The  most  basic  type  of  gbiock  is  the  LINE.  It  is  formally  defined  as  being 
composed  of  three  subsequences  of  characters:  those  before  and  after  the  cursor  plus 
those  under  the  cursor  itself.  The  only  restriction  on  this  structure  is  that  the  cursor 
sequence  is  non-empty: 

LINE - - 

I  before*  cursor,  after:  seq  Char 


acursor  2  1 


A  CARTOUCHE  has  only  two  parts:  a  gbiock  and  some  unspecified  quantity  taken 
from  the  set  [UALUEl.  (The  reader  should  note  that  this  latter  component  of  a 
CARTOUCHE  is  of  no  concern  to  this  specification  -  its  declaration  is  given  only  for 
the  sake  of  completeness.) 

r  CARTOUCHE _ , 

VI  VALUE 
9b:  GBLOCK 


To  specify  the  notions  of  HORUECs  and  UERUECs  it  is  necessary  to  go  through  two 
stages.  The  first  consists  of  a  'partial*  definition;  a  second  stage  presented  later 
expands  this  to  a  'total'  definition. 

A  PARTIALJHORUEC  is  one  made  up  of  three  subsequences  of  gbiocks  in  a  manner 
similar  to  that  of  a  LINE.  The  sequences  notionally  run  from  left  to  right. 

PARTIAL_HORVEC _ , 

before,  cursor,  after:  seq  GBLOCK 


acursor  2  1  ^ 

- 1  \ 

A  PARTIALJJERUEC  has  an  identical  specification  to  that  of  a  PARTIAL_HORUEC  i 

but  here  the  elementary  gbiocks  within  each  subsequence  notionally  run  from  top  to  j 

bottom  (see  Section  1). 

PARTIAL.UERUEC  a  PARTIAL.HORVEC  j 

Given  these  definitions  so  far,  one  can  easily  see  that  they  model  the  recursive  I 

nature  of  gbiocks.  It  is  also  noticeable  that  of  the  four,  only  the  line  type  gbiock  is  j 

not  recursively  defined. 

The  next  stage  of  the  formalisation  is  to  define  some  method  by  which  we  can  ^ 
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distinguish  between  the  four  types  of  gblocks  or,  in  other  words,  given  a  gbiock  we 
can  discover  its  type.  In  Z,  the  distinction  is  modelled  as  four  functions: 


line  ; 

GBLOCK 

LINE 

horvec  : 

GBLOCK 

M* 

PftRTIflL_HORUEC 

vervec 

GBLOCK 

PftRTIftL  UERUEC 

cartouche: 

GBLOCK 

CPRTOUCHE 

(dom  line. 

dom  vervec,  dom  horvec,  dom  cartouche) 

par  t i t i on  GBLOCK 

The  predicate  informs  us  that  no  type  of  gbiock,  other  than  the  given  four  exists 
and  furthermore,  that  each  gbiock  is  of  exactly  one  type. 

These  four  'type  determining*  functions  above  allow  us  to  embark  on  the  second 
stage  of  the  definitions  for  HORVECS  and  VERVECS:  a  "total"  horvec  is  one  which 
contains  no  horvecs  in  any  of  its  subsequences  and  similarly,  a  'total*  vervec  contains 
no  vervecs.  (We  shall  dub  this  the  'no  X  in  X*  rule). 

HORUEC _ , 

PflRTIAL_HORyEC 


ranCbefore  ~  cursor  ~  after)  n  (dom  horvec)  =  ■(> 


UERUEC  _ 

PRRTIAL_UERUEC 


ran(before  ”  cursor  “  after)  n  (dom  vervec)  =  {> 


ahe  reason  for  the  two  stages  should  now  be  clear  -  the  full  definitions  require 
the  declaration  of  the  "typing*  functions.) 

The  "no  X  in  X"  rule  is  introduced  to  exclude  confusion  for  the  user  -  when 
displayed,  there  is  no  visible  difference  between  a  vervec  containing  no  vervecs  and 
one  containing  several  but  the  structural  discrepancies  can  show  up  when  certain 
functions  are  performed.  As  a  side  effect  of  its  specification,  the  "no  X  in  X"  rule 
shortens  any  proofs  that  we  may  carry  out  on  the  operation  of  MaCHO*I  by 
eliminating  one  class  of  problem  from  consideration  when  analysing  the  subelements  of 
horvecs  and  vervecs. 

One  additional  constraint  is  necessary  for  gblocks,  namely  that  their  definitions  are 
non-circular.  To  realise  this  notion  we  make  use  of  a  relation  contains. 

I  contains:  GBLOCK  «  G6L0CK 


Da,  b:  GBLOCK  . 

(a,  b )  c  contains 
(a  e  dom  horvec  a 

b  c  ran  ( (horvecia  )). before  "  (horvec(a  )  ).cursor  ~ 

(horvec(a ) ). after  ) ) 

V 

(a  c  dom  vervec  a 

b  e  ran  ( (vervec(a  )). before  '*  (vervec(a  )). cursor  ^ 

(vervsc(s  ) ). after  ) ) 

V 

(a  c  dom  cartouche  a  b  -  (cartouche! a )  l.gb ) 

contains  holds  those  pairs  of  gblocks  (g,g')  such  that  gbiock  g’  exists  somewhere 
in  the  internal  structure  of  gbiock  g.  Lines  therefore  contribute  no  elements  to  the 
domain  of  contains  (but  obviously  there  may  be  ssany  such  gblocks  in  its  range). 


One  statement  now  suffices  to  give  us  a  full  embodiment  of  non-circularity: 
contains^  D  (id  GBLOCK )  «  O 

The  formal  specification  of  the  data  structures  is  now  complete  but  for  the  sake  of 
brevity  and  clarity  in  the  remainder  of  the  document,  we  shall  define  schemas  which 
allow  for  their  easier  manipulation. 

For  horvecs,  vervecs  and  lines  it  is  useful  to  be  able  to  refer  to  only  one  of  their 
three  constituent  sequences: 

rCXl  —  I 

«#  1:  GBLOCK  saq  X 


d  g:  doin  horvac  • 

«  3  =  h. after  a  P  9  =  h. before  a  T  9  =  h. cursor 
where 

h  a  horvecC  9  1 
d  g:  dotn  vervec  • 

ot  3  =  V. after  a  P  g  =  v. before  a  T  9  =  v. cursor 
where 

V  a  vervecC  g  ) 
d  g:  dom  line  • 

01  9  =  l.after  a  P  9  =  1-before  a  1  9  =  1. cursor 
where 

1  a  lineC  g  ) 

It  is  also  useful  to  be  able  to  bind  the  three  subsequences  together: 

rlXl  I 

bind:  GBLOCK  seq  X 


d  g:  GBLOCK  •  bindg  =  ''/<  pg,  Tg.  wg  > 


As  a  sort  of  inverse  to  BIND,  we  need  functions  which  given  a  sequence  of 
objects  (in  this  case  GBLOCKs  or  CHBRs)  constructs  a  single  GBLOCK  out  of  them: 

RtXl -  , 

make:  seq  X  GBLOCK 


d  s:  seqi  X  • 
p  (make  s )  =  < ) 
1  (make  s )  =  5 
n  (make  s  )  =  ( > 


to 


Cartouches  have  different  components  to  lines,  horvecs  and  vervecs  and 
consequently  have  different  methods  by  which  to  access  them  individually: 

I  t:  CBLOCK  GBLQCK 
VI  GBLOCK  «  UBLUE 


Bg:  dom  cartouche  . 

r  s  ^  (cartoucheC  9  ))*sb 
us-  (cartouche!  g  )),v 

(The  Greek  letters  used  above  are  chosen  to  be  aide-memoires:  «  for  'after',  g  for 
"before"  and,  in  the  absence  of  a  Greek  'c',  'i  for  "cursor",  t  is  derived,  somewhat 
dubiously,  from  carTouche  and  u  appears  courtesy  of  its  similarity  to  "V  as  in 
"value"!) 
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SttioB  38  Biic  OpOTtow  md  Comfirti 


The  first  besic  operator  we  introduce  is  one  to  sum  a  sequence  of  natural  numbers: 
I  I:  seq  N  -  N 


Z  <>  -  0 

I  seq^  N  •  Z  s  =  (hd  s )  ‘t-  Z  (tl  s) 

To  create,  alter  and  move  objects  in  the  MaCHO  Interface  >  and  indeed  any  other 
interface  -  we  must  know  (or  be  able  to  determine)  the  height  and  width  of  the 
individual  objects: 

-  - - - 

I  hei.  Mid:  Y  ^  N 

Given  that  we  can  find  the  width  of  single  objects,  we  can  now  find  the  width  and 
height  (in  pixels)  of  an  entire  sequence  of  objects: 


(=m: - - - - 

suRiMid,  suinhei:  seq  Y  -•  N 


l^s:  seq  Y  « 

sumwid  s  ^  Z  (si  Mid ) 
sumhei  s  °  Z  (si  hei  ) 


j 

and  we  can  also  discover  the  height  of  the  highest  and  the  width  of  ;he  widest 
object  in  a  sequence  of  objects: 


maxwid,  maxhe 

:  seqj  Y  -t  N 

==l 

y  s!  seqj  Y  . 

maxMid  s  = 

max  (Midf  ran  s 

J) 

maxhe i  s  = 

max  (heif  ran  s 

1) 

For  MaCHO-I  we  also  need  functions  which  split  sequences  according  to  some 
general  methodology;  that  is,  given  a  sequence  we  can  return  certain  parts  of  it 
which  are  determined  by  the  result  of  a  supplied  function: 
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(J.DSPLIT_).  (J<ISPLIT_): 

(seq^  Y  «  (N  *  (seq  Y  ■»  N)))  ■»  seq  Y 


Ws.  t:  seq^  Y;  u:  seq  Y;  n:  N:  f:  seq  Y  -»N|s  =  t'‘u. 
f  t  >  n 

f  (front  t )  S  n 
s  LOSPLIT  (n,  f )  >  t 
s  HISPLIT  Cn.  f )  *  u 


s  LOSPLIT  (n<  f)is  that  part  of  s  up  to,  but  not  including,  the  first  element 
whose  'value',  as  determined  by  function  f,  is  greater  than  n.  s  HISPLIT  (n,  f) 
returns  the  other  'half*  of  s. 

A  blank  gblock  is  a  line  type  gblock  with  only  a  single  space  character  in  its 
cursor: 

I  space :  Char 
blank:  dom  line 


p  blank  -  <  > 

Y  blank  =  <  space  > 
M  blank  -  <  > 


SactioH  4;  FradtdOTd  FunctloM 


All  of  th«  functions  in  the  MeCHO  Interface  take  as  (part  of)  their  input  a  gblock 
and  a  stack  of  remembered  elements,  this  latter  being  formally  specified  as  a  seauence 
of  ghlocks.  These  two  parameters  to  the  function  are  called  the  input  STATE. 

STATE _ _ 

9:  GBLOCK 

stack :  saq  GBLOCK 

■ 

Every  function  delivers  another  STATE  as  its  output  and  so  in  general  we  have: 

FUN _ , 

f:  STATE  STATE 

To  move  the  cursor  on  the  display  we  use: 

I  left,  riaht,  up,  down:  STATE  STATE 

To  rub  out  characters  to  the  left  of  the  current  cursor  (sometimes  referred  to  as 
backspace)  we  use: 

I  del_left:  STATE  STATE 

and  to  erase  those  characters  "underneath*  the  current  cursor, 

I  del.riaht:  STATE  STATE 

Grouping  several  characters  or  gblocks  together  to  form  a  large  cursor  is 
performed  by 

I  group_left,  group_ri9ht,  group_up,  group_doMn:  STATE  STATE 

whose  inverses  are: 

Iungroup_left,  ungroup_r ight , 

ungroup_up,  ungroup.doMn:  STATE  >«  STATE 

Having  grouped  some  gblocks  together  under  the  cursor,  we  may  wish  to  delete  this 
structure  onto  the  stack  of  the  input  STATE  which  can  be  achieved  by  the  function: 

I  deljelement:  STATE  «•  STATE 

Another  method  of  adding  elements  to  the  current  stack  of  the  input  but  without 
altering  the  display  is  to  duplicate  those  gblocks  which  are  currently  "under"  the 
cursor: 

I  duplicate:  STATE  STATE 

Once  on  the  current  stack  of  remembered  elements,  a  gblock  can  be  reinserted  into 
the  display  in  two  amnners  -  horizontally,  that  is  immediately  in  front  of  the  cursor, 
or  vertically,  i.e.  immediately  above  the  cursor: 

I  ins_Bbova,  lns_beFore:  STATE  STATE 
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An  entirely  new  blank  line  type  gbiock  can  be  inserted  in  the  display  either  above 
or  below  the  current  cursor: 

I  blank_above>  blank_bclou:  STATE  -m  STATE 

Whenever  the  current  cursor  is  covering  a  cartouche,  we  can  recover  the  gbiock 
which  is  associated  with  the  cartouche  (  «  cartouche!  cursor  l.gb  *  using; 

I  undo:  STATE  «  STATE 

All  of  the  above  functions  can  be  abstracted  away  into  schemas,  using  schema 
FUN: 

Right  a  [  FUN  |  f  *  right  1 
Left  a  [  FUN  I  f  *  left  1 

Up  a  [  FUN  I  f  -  up  ] 

Down  a  t  FUN  |  f  *  down  ] 

DelLeft  a  [  FUN  |  f  »  del.left  1 
DelRight  a  (  FUN  |  f  >  del_ri9ht  1 
GroupLeft  a  (  FUN  |  f  ^  group.left  1 
GroupRight  a  (  FUN  I  f  >  group_right  1 
GroupDown  a  [  FUN  |  f  >  group_dOMn  1 

GroupUp  a  [  FUN  |  f  »  groupjjp  1 

UngroupLeft  a  I  FUN  |  f  >  ungrQup_left  ] 

UngroupRight  a  t  FUN  I  f  *  ungroup_r > ght  1 
UngroupUp  a  (  FUN  |  f  «  ungroup_pp  1 

UngroupOown  a  (  FUN  |  f  *  ungroup_down  1 

DelElement  a  [  FUN  |  f  >  del_alement  1 
Duplicate  a  t  FUN  |  f  >  duplicate  1 
InsAbove  a  (  FUN  |  f  *  insjafaove  1 
InsBefore  a  I  FUN  |  f  «  ins_l>eforc  1 
BlankAbove  a  C  FUN  |  f  *  blank_above  1 
BlankBelow  A  t  FUN  j  f  >  blank^elow  1 
Undo  a  C  FUN  I  f  B  undo  1 

and  their  inputs  and  outputs  can  be  modelled  using  the  schema  10: 

10  a  t  a.  s':  STATE  1 

However,  two  functions  implemented  in  the  interface  cannot  be  abstracted  as  above 
since  their  inputs  are  not  just  a  single  STATE:  inB_chsr  is  the  function  that  is  called 
every  time  the  user  hits  a  key  on  the  keyboard  and  thus  has  the  struck  character  as 
part  of  its  input,  and  go  in  is  the  function  that  is  called  when  the  user  moves  the 
cursor  between  different  gbiocks  on  the  screen  -  necessitating  the  coordinates  of  the 
point  selected  to  be  included  in  the  input  parameters. 

I  insjchar:  (STATE  »  Chsr )  STATE 
I  go  in:  (STATE  »  N  »  N )  STATE 

We  can  though  still  model  the  input  and  output  state  parts  for  in5_ch8r  and  go  in 
using  ID. 


IS 


S«ctloii  &  Window  III  tht  MaCHO  IntTf^ 


Every  coordinate  in  the  MaCHO  Interface  is  represented  by  a  pair  of  non-negative 
numbers: 

COORD  a  (N  «  N) 

A  BRECT  is  a  rectangular  area  defined  by  the  coordinates  of  its  top  left  and 
bottom  right  corners: 

BRECT _ , 

tl.  br:  COORO 

fate  tl  )  S  fst(  br  ) 
snd(  tl  )  i  snd(  br  ) 


The  windowing  scheme  of  the  MaCHO  Interface  is  specified  as  a  function  between 
BRECTs  and  STBTEs  where  the  BRECT  defines  the  window  through  which  the  gbiock  of 
the  STATE  it  is  mapped  to  is  seen.  (Recall  from  Section  1  that  the  stack  of 
remembered  elements  in  a  state  is  not  shown.) 

P  HindoHs:  BRECT  STATE 

As  may  be  guessed,  however,  there  are  constraints  on  the  elements  of  the 
windowing  scheme  so  far  presented  whose  descriptions  require  the  declaration  of  some 
auxiliary  functions. 

Firstly,  we  define  a  function  which  returns  the  set  of  coordinates  "covered"  by  a 
BRECT: 

I  cover:  BRECT  -  P  COORO 


bb:  BRECT  . 

cover (  b  )  =  <x:  (fst(  b.tl  )  ..  fst(  b.br  )); 

y:  (snd(  b.tl  )  ..  snd(  b.br  ))  •  (x,  y )> 

Next,  we  define  a  special  BRECT  which  defines  the  area  the  user  has  available  to 
work  in  and  two  integers  which  define  the  maximum  dimensions  of  any  gblcck; 

I  workspace:  BRECT 
I  xmax,  ymax:  N 

Using  the  above,  we  expand  the  specification  of  the  MvCHO  windowing  scheme  by 
insisting  that 

•  the  windows  completely  cover  the  available  space, 

•  no  two  windows  overlap, 

•  and  no  gbiock  has  a  size  greater  than  the  maximum  allowed. 
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UIND0U5 

I  U 


U  cover!  dom  Hindowe  I  ■  cover (  Morkspace  ) 
b  p>  q:  dom  MtndoMS  |  p  e  q  •  covert  p  )  n  covert  q  )  =  {> 
s:  ran  windous  •  tuid  s.g)  $  xmax  ^  (hei  s-g)  S  ymax 


Under  the  constraints  of  UINOOUS,  «e  can  construct  an  initial  system  state  in 
which  there  is  only  one  window  whose  associated  gblock  consists  of  a  blank  line  type 
gblock  and  whose  stack  of  remembered  elements  is  empty: 

INITIrtI _ _ 

AUINDOUS 


MindoMs'  K  -Cuorkspace  m  s> 
where 

I  S!  STATE 


s. stack  =  t ) 
s.g  -  blank 


S«ctioii  6s  BaaUi  Sch—t 


In  this  section  we  introduce  some  besic  schemas  which  will  be  used  in  various 
places  throughout  the  remainder  of  the  document 

The  first  schema  is  a  simple  one  containing  just  two  natural  numbers  which  can 
represent  an  absolute  coordinate  in  the  workspace  or  a  relative  offset  from  some 
point: 

XY  a  f  X,  y:  N  ] 

flXY  a  I  XY;  XY'  1 

(Although  XY  is  identical  to  COORO  in  section  6,  we  declare  XY  seperately  since  it 
is  to  be  used  in  a  different  way.) 

Related  to  the  above  is  a  schema  which  sets  the  two  values  in  XY  to  zero: 

SetO _ _ 

axY 


x’  =  y'  =  0 


Another  simple  schema  to  define  is  one  whose  action  is  the  null  action: 

rNull  . 

10 

HUINOOUS 


The  next  three  schemas  define  the  types  of  the  gblock  which  are  passed  in  and 
out  of  the  functions  of  the  interface: 

VOps _ , 

10 


s-s  c  dam  vervec 
s’. 9  €  dom  vervec 


LOps 

10 


s.g  e  dom  line 
s* .g  c  dom  1 ine 
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I 


HOps 

ID 


s.g  c  doM  horvcc 
s’.g  c  dom  horvcc 


and  the  next  two  define  the  type  of  the  (block  at  the  top  of  the  ttack  of 
remembered  elements  in  a  given  state: 

—  TopHorvec  , 

I  ID 


hd  (s- stack)  c  dom  horvec 
s’  >  s 


TopUervec 

I  ID 


hd  (s. stack  )  c  dom  varvec 
s’  «  s 


We  use  XY  in  a  schema  which  describes  the  action  of  "going  in'  to  a  single  gblock 
in  a  sequence  of  (blocks: 


10 

sUINDOUS 

SXY 


a.g)  =  1 
p  s’.g  =  g  s.g 
Y  s’ .g  =  <  result. g  > 

«  s’.g  «  s.g 
s’. stack  *  result. stack 
where 

I  5t>  result:  STATE 


st . g  =  hd  ( Y  s.g) 
st. stack  «  s. stack 
result  >  goinC  st .  y  ) 


5  is  defined  only  when  the  (block  that  is  entered  is  the  unique  element  in  the 
cursor  sequence  of  the  input  state. 

The  most  difficult  operation  to  specify  in  this  section,  and  probably  in  the  entire 
document,  is  that  of  normalisation  so  we  will  go  through  it  in  some  detail  here. 

By  normalisation,  we  aiean  the  moulding  of  horvecs  and  vervecs  into  their  canonical 
fonns  without  lots  of  information.  This  process  has  three  distinct  stages: 

•  transform  the  object  into  a  sequence  of  its  constituent  (blocks, 

•  process  this  sequence  to  remove  any  undesirable  features, 

•  partition  the  processed  sequence  into  three  subsequences  to  form  the 
before,  cursor  and  after  sequences  of  the  result. 


1 
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Thi*  firci  stage  is  performed  by  the  binding  function  of  section  1:  the  intermediate 
stage  is  responsiWe  for 

•  correcting  any  degenerate  gblocks. 

•  reaioving  horvecs  from  horvecs  and  vervecs  from  vervecs,  in  order  to 
conform  to  the  'no  X  in  X‘  rule  of  section  2,  and 

•  merging  adjacent  line  type  gblocks  On  horvecs  only). 

For  the  first  of  these  processes,  we  need  to  define  what  a  degenerate  gblock  is: 

I  deaencratei  f  GBLOCK 


I  degenerate  >  Cg:  dam  horvec  U  dam  vervec  I  e  (bind  g )  >  1> 

-  a  degenerate  gblock  is  a  horvec  or  a  vervec  which  contains  only  one  gblock. 
During  normsdisation  of  a  sequence  of  gblocks  degenerate  gblocks  are  removed  and 
replaced  by  the  single  element  they  contain: 

I  purge:  seq  GBLOCK  -•  seq  GBLOCK 


purge  <  >  »  < ) 

d  g:  degenerate  •  purge  <g>  >  bind  g 
b  g:  GBLQCK\degenerate  •  purge  <g>  °  <g> 

d  s,  t:  seq  GBLOCK  •  purge!  s  ''  t  )  *  purge!  s  )  ^  purge!  t  ) 

In  a  fashion  similar  to  that  of  purge,  the  second  process  is  defined  as  a  function 
which  seeks  out  specific  types  of  gblock  in  a  sequence  and  replaces  them  with  their 
flattened  versions  *  helim  for  eliminating  horvecs,  velim  for  eliminating  vervecs: 

I  helim;  seq  GBLOCK  -•  seq  GBLOCK 


helim  ! >  »  ! > 

d  g:  dam  horvec  •  helim  !g>  ■  bind  g 
d  g:  GBLOCKNdom  horvec  •  helim  <g>  *  !g> 

d  s.  t:  seq  GBLOCK  •  helim!  s  ^  t  )  =  helim!  s  )  *  helim!  t  ) 
velim:  seq  GBLOCK  -•  seq  GBLOCK 


vel i m  ! >  =  ! > 

d  g:  dom  vervec  •  velim  !g)  »  bind  g 
d  g:  GBLOCKNdom  vervec  •  velim  !g>  >  !g> 

d  s#  t:  seq  GBLOCK  .  velim!  s  ^  t  )  *  velim!  s  )  ^  velim!  t  ) 

To  specify  the  third  process  of  merging  adjacent  line  type  gblocks  we  need  an 
auxiliary  function  which  makes  one  line  out  of  two: 


20 


mcrgas  mmq  CS.OCK  -•  Mq  GSLKK 


merge  < )  >  ( > 

U  g:  GBLOCK  •  merge  <g>  >  <g> 

B  t:  eeq  GBLOCK;  p>  q:  dam  line  • 

merge(  s  "  (p>  ^  <q>  “  t  )  *  merge(  •  <p  join  q>  ^  t  ) 

B  Sr  t:  seq^  GBLOCK  |  (lest  s  <  dom  line)  v  (hd  t  S  dom  line)  • 

mergeC  s  *'  t  )  ■  mergeC  s  )  Mrge(  t  ) 

The  fine!  ttege  of  normelisation,  splitting  the  processed  sequence,  is  performed  by 
determining  the  first  element  of  the  cursor  seqtwnce  end  then  specifying  the  length  of 
this  sequence.  To  help  to  do  this,  we  define  a  function  which  returns  a  sequence 
containing  just  those  elements  of  another  Oarger)  sequence  whose  indices  in  this  latter 
are  members  of  a  given  set. 


(_  1  (P  N  «  seq  X)  -*  saq  X 


W  v;  P  N  .  V  1  <  >  =  <  > 

B  s:  seq  X  .  <>  1  s  =  <  > 

B  v:  Pj  N;  s:  seqi  X;  n:  N  . 

n  c  dom  s  -Cn}  1  s  »  <s(n)> 

n  S  dom  s  aw  <n>  1  s  =  < ) 

v1s=('Cminv>  Is)'*  ((vV'Cmin  v> )  1  s) 


Putting  the  three  stages  together  we  obtain  the  desired  specifications: 

BNorm  _ 

10 

EUINDQUS 

BOps 

XY 

n:  N 


0  s’ .g  *  front  p 
1  s’.g  »  (l..n)  1  q 
n  s' .g  *  (n+l  , .  aq )  i  q 
s' .stack  s  s. stack 
where 

V  a  (binds  velims  purge)  (s.g) 

p  £  V  LOSPLIT  (y,  sumhei  ) 

q  S  <  last  p  >  ^  (v  HISPLIT  (y,  sumhei  )) 


HNorm  __ 

10 

sUINDOUS 

HOps 

XY 

n;  N 


0  s’.g  ■  front  p 
Ts’.g*  (1  ..  n)  1  q 
M  s’ .g  >  (n+1  . .  aq )  1  q 
s’. stack  B  s. stack 
whara 

h  £  (binds  halims  purgas  marga )  (s.g) 
pah  LOSPLIT  (x#  sumwid) 
q  a  <  last  p  >  ''  (h  HISPLIT  (x,  sumwid)) 


21 


S«cticii  7;  ItoCMTiioa  la  th»  MaCHO 


The  aim  of  this  docuoient  it  to  formally  specify  the  behaviour  of  the  MaCHO 
Interface  or,  more  precisely,  the  effect  of  certain  operations  on  its  underlying  data 
structure.  Given  the  recursive  nature  of  this  last  item,  it  it  natural  that  most  if  not 
ail  of  the  functions  to  be  specified  are  themselves  recursive  in  one  way  or  another.  In 
this  section  we  describe  the  general  form  this  recursion  takes. 

If  we  were  to  classify  horvecs  or  vervecs  in  MaCHO-I  according  to  the  number  of 
elements  in  their  cursor  sequences,  we  could  choose  to  distinguish  two  classes  -  those 
with  cursors  containing  two  or  more  gblocks  and  those  with  cursors  of  size  exactly 
one.  It  is  this  latter  class  of  gblocks  which  give  rise  to  the  recursion  in  the  interface: 
in  these  cases  the  result  of  applying  a  function  to  the  horvec  or  vervec  concerned  is 
determined  by  the  type  of  the  single  gblock  in  its  cursor  and  on  whether  the  function 
can  be  recursively  applied  to  this  same  gblock.  In  (very)  pseudo  Pascal  terms  we  have: 


FUNCTION  f  (gi  GBLOCK):  GBLOCK; 

BCG  IN 

IF  * 

g  is  a  horvec  or  a  vervec  AND  * 

size  of  cursor  >  1  AND  • 

cursor  gblock  of  g  is  a  valid  argument  for  f  • 

THEN  * 

BEGIN  • 

cursor  gblock  of  g  f(  cursor  gblock  of  g  ) i  • 
optionally  alter  g  with  its  new  cursor; 
result  :=  g  • 

END  • 

ELSE 

do  something  else  to  g  and  return  result; 


END; 

From  the  above  we  see  that  the  recursive  call  can  be  followed  by  further 
alterations  of  the  input  gblock  to  yield  t)te  result;  we  will  come  across  examples  of 
this  behaviour  in  the  document  subs^uently.  In  this  section,  we  content  ourselves,  to 
begin  with,  by  formlly  specifying  the  recursive  call  part  (amrked  •)  for  a  general 
function  from  STATE  to  STATE: 

Recur - - 

HUINOOUS 

10 

FUN 


a(1  s.g )  =  1 
st  e  dom  f 
P  s’ .g  =  B  s.g 
T  s’ .g  *  (result. g) 
m  s’ .g  a  «  s.g 
s’. stack  a  result. stack 
where 

I  st,  result:  STATE 


st.g  a  hd  (T(gbl0CK1 
St. stack  a  s. stack 
result  a  f(  St  ) 


DRccur  m  Recur  a  V^Ops 

HRecur  A  Recur  a  HOps 

(Note  that  in  the  informal  code  we  talked  about  GBLOCKs  whereas  the  formal 
specification  makes  reference  to  STATES  as  is,  of  course,  actually  required.) 

With  this  general  description  of  recursion,  we  can  easily  describe  recursive  calls  of 
specific  functions  from  the  previous  section  by  'and'ing  in  the  matching  schema.  For 
instance,  the  recursive  part  of  the  function  (cursor)  left  applied  to  a  vervec  is 
modelled  by: 

VLeft  *  URecur  a  Left 

To  formally  specify  a  function  in  full  we  use  the  schema  override  notation  a  where 
for  schemas  S  and  T: 

S  •  T  g  ( -«pre  T  a  S )  y  T 

This  notation  models  precisely  and  succinctly  the  ‘if..then..else..'  construction  of  the 
pseudo  code: 

UFunction  g  (JOoSometh ingElsc  #  (tlRecur  a  Function) 

and  it  will  therefore  be  often  used  in  the  ensuing  text. 

For  the  function  ins_chsr  we  require  a  similar  recursion  scheme  to  that  just 
presented  but  one  which  takes  into  account  the  extra  character  parameter  of  the 
ins_char  operation; 

rInsCharRecur  _ 

10 

sUINOOUS 
Cl  Char 


M( 1  S.9  )  ■  1 

(st>  c)  a  dom  ins.char 

P  s’ .9  ■  B  s.9 

1  s' .9  ■  <  rasult.g  ) 

«  s*  .9  ■=  w  g*9 

s’. stack  >  rasu It. stack 
Mhara 

I  st>  rasult:  STATE 


St. 9  *  hd  (TjceLOCK) 

st. stack  >  B. stack 

rasult  w  insjeharf  st>  c  ) 


VInsCharRacur  g  InsCharRacur  a  VOps 
HInsCharRacur  g  InsCharRacur  a  HOps 
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Section  j;  Golna  In  (to  the  data  ttnictuf) 


I 


In  order  to  edit  text  displayed  on  the  screen  it  must  be  possible  to  select  the 
object  or  objects  to  be  manipulated.’  In  MaCHO-I.  an  object  is  selected  by  positioning 
the  pointer  (see  section  1)  at  a  certain  (x.  y)  displacement  from  the  top  left  hand 
corner  of  the  outermost  gblock  in  a  window  (see  section  4)  and  'going  in'.  In  the 
interface  itself,  this  corresponds  to  the  action  of  plummeting  down  from  the  outermost 
gblock  through  the  various  levels  of  structure  until  a  basic  gblock,  that  is,  a  line  or  a 
cartouche,  contained  therein  is  found. 

When  a  line  type  gblock  is  found  at  the  lowest  level,  the  supplied  (x,y)  parameters 
determine  a  unique  element  from  the  sequence  of  characters  within  the  gblock.  The 
character  thus  selected  becomes  the  cursor  of  the  line  from  whence  we  can  define 
the  pre-  and  post-cursor  sequences  of  the  line.  However,  to  go  into  a  line,  we  need 
to  check  the  x  displacement  supplied;  if  it  yields  a  point  beyond  the  end  of  the  line, 
we  extend  the  line  up  to  this  point  with  a  sequence  of  space  characters.  This 
padding  is  performed  by  the  function  pad: 

I  pad :  ( seq  Char  >  N )  4*  seq  Char 


d  s:  seq  Char;  n:  N  |  n  <  sunwid  s  •  pad(s,  n  )  =  s 
d  s:  seq  Char;  n;  N  j  n  k  sumwid  s  • 

pad(s,  n)  =  pad(s  ''  (space),  n) 


LGoIn  _ 

aU I NODUS 

10 

LOps 

aXY 


p  s' . g  =  front  p 
1  s’ .g  =  <  last  p  > 
w  s’.g  =  1  HISPLIT  (x,  sumwid) 
s’. stack  s  s. stack 
where 

1  a  pad(  (s.g),  x  ) 

pad  L05PLIT  (x.  sumwidj^^^^j )) 


Going  into  a  cartouche  is  at  the  same  time  the  most  simple  and  complicated 
operation  in  this  section.  The  simple  case  occurs  when  the  x  displacement  given  lies 
somewhere  along  the  length  of  the  cartouche  for  then  the  result  of  the  operation  is 
merely  the  same  as  the  input: 

rCGoInSimpla _ , 

aUINDOUS 

10 

EXY 


s.g  c  dom  cartouche 
X  <  wid  s.g 
s’  »  B 


If  on  the  other  hand  the  x  displacement  lies  somewhere  beyond  the  length  of  the 
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cartouche,  the  gblock  part  of  the  result  is  a  horvec.  This  horvec  is  created  from  the 
cartouche  and  a  blank  line  which  extencb  from  the  rightmost  edge  of  the  cartouche  to 
the  selected  point: 


^CGoInComplsx  . 

HUIND0I45 

10 

=XY 


B-s  €  dom  cartouche 

X  2  Mid  S.9 

s'. 9  e  dom  horvec 
p  s' .g  =  <  s.g  > 

1  s' .9  =  <  1  ) 

«  s' .9  =  < ) 
s'. stack  -  s. stack 
where 

1  s  '"®*‘®[Char  1  ^  (  >»  X  -  widl  s. 


)  )  ) 


CGoIn  a  CCoInComplex  v  CGoInSimple 

The  first  part  of  the  definition  of  go  in  for  a  vervec  is  similar  to  that  for  a  line, 
inasmuch  as  the  (x,  y)  parameters  select  an  object  to  be  the  cursor  for  the  structure 
and  from  this  the  rest  of  the  vervec  is  defined.  Obviously  though,  for  a  vervec.  it  is 
the  distance  down  the  structure,  the  y  displacement,  which  determines  the 
partitioning; 

yPar  t  i  t  i  on  _ _  ^ 

sUINDQUS 

10 

OOps 

AXY 


p  s' .g  “  front  p 

Y  s' .g  =  <  last  p  > 

w  s'.g  =  V  HISPLIT  (yy,  sumhei  ) 
s' .stack  s  s. stack 
x'  =  X 

y'  =  yy  ~  sumhei (  p  s'.g  ) 
where 

V  e  GBLOCK]^  ^ 

yy  s  min  fy,  sumhei!  v  )  -  1> 
p  a  V  LOSPLIT  (yy.  ®tjmhei  [gg[_gQ|^]  ) 


Note  that  the  displacement  used  to  partition  the  vervec  (yy)  is  the  lower  of  the 
maximum  possible  displacement  (the  height  of  the  entire  vervec  minus  one)  and  the 
original  y  parameter. 

The  next  and  final  stage  of  the  definition  of  90  in  for  a  vervec  is  to  recursively 
'go  in'  to  the  gblock  in  its  cursor  with  the  displacement  calculated  from  the 
partitioning  stage; 

OGoIn  a  (IPartltioni  5 

For  a  horvec,  the  partitioning  part  of  go  in  is  almost  identical  to  that  for  a 
vervec  '  with  the  obvious  exception  that  it  is  the  distance  along  the  structure  which 
determines  the  components  of  the  result  and  thence  it  is  the  widths  of  the  gblocks  in 
the  sequence  which  is  important: 
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HPart it  ion 

SUINOOUS 

10 

HOps 


p  s’ .9  =  front  p 
t  s’ .9  =  <  last  p  ) 

01  s’. 9  »  h  HISPLIT  (xx,  sumwid) 
s’ -stack  =  s. stack 
x’  >  X  -  sumwidC  9  s’. 9  ) 
y’  -  y 
Mhere 

h  fi  b'ndfgaLOCK]  ^*'9^ 

XX  a  min  {x>  sumwid(  h  )  -  1> 

P  s  h  LOSPLIT  ( XX f  ^ CQLQQK 1 ^ 


Analogously  to  vervecs  again,  the  second  stage  in  the  defintion  of  go  i  n  for  a 
horvec  consists  of  a  recursive  “go  in"  to  the  cursor  gblock:  in  horvecs,  however,  this 
is  not  the  last  stage  -  as  it  is  for  vervecs  -  since  we  require  that  the  result  from  the 
second  stage  described  by  schema  S  to  be  normalised.  The  extra  processing  required 
is  to  handle  the  case  when  the  user  selects  a  point  beyond  the  rightmost  end  of  a 
horvec  whose  last  element  is  a  cartouche:  the  resulting  "go  in"  to  the  cartouche 
would  result  in  a  horvec  within  a  horvec  by  definition  of  CGoInComplex.  Thus  we 
have: 

HGoIn  A  HPartitionJ  SJ  HNorm 


Saction  9i  Curtor  Control  Fuactioai 


At  any  stage,  we  nay  wish  to  change  the  position  of  the  cursor,  away  from  that 
established  by  the  initial  90  in.  For  large  novements  we  can  of  course  execute  a 
further  goin  at  the  desired  point  but  if  we  want  only  to  move  to  the  adjacent 
character  or  gblock  it  is  simpler  (and  more  efficient)  to  use  the  normal  cursor 
movement  commands  -  cursor  left,  cursor  right,  cursor  up  and  cursor  down. 

To  specify  such  movement,  we  introduce  two  schemas  -  StepForw  to  move  the 
cursor  sequence  of  a  gblock  onto  the  first  element  of  the  postcursor  sequence  and 
StepBack  to  move  it  onto  the  last  element  of  the  precursor  sequence: 

rStepForM  _ 

10 

HUINDOUS 


e  s’  .g  =  (p  s.g )  •'  (1  S.9 ) 
1  s'. 9  =  <  hd  («  s.g)  ) 
n  s' .g  =  tl  (m  s.g ) 
s'. stack  =  s. stack 


rStepBack 
10 

sUINOOUS 


p  s’ .g  *  front  (p  s.g ) 

1  s’.g  *  <  last  (p  s.g)  ) 

01  s'.g  ■  (t  s.g)  (n  s.g) 
s'. stack  s  s. stack 


In  a  vervec,  cursor  movement  up  or  down  takes  place  in  two  stages  -  the  first 
changes  the  structure  according  to  the  relevant  *step'  schema  above  and  the  second 
recursively  ‘goes  in*  to  the  newly  defined  cursor: 

l>0oMn  P  ((StepFoTH  a  UOps  )i  5)  •  ((/Recur  a  Domh  ) 

(/Up  P  ((StepBack  a  (/Ops  )A  5)  #  ((/Recur  a  Up) 

As  a  horvec  is  a  horizontal  sequence  of  gblocks,  a  call  to  move  the  cursor  up  or 
down  it  only  makes  sense  if  the  operations  can  be  recursively  applied: 

HUp  P  HRecur  a  Up 

HDown  P  HRecur  a  OoHn 

Moving  left  in  a  line  is  easily  specified: 

LLeft  P  StepBack  a  LOps 

and  moving  left  in  a  horvec  is  defined  analogously  to  moving  up  in  a  vervec: 

HLeft  P  ((StepBack  a  H0ps)J  S)  a  (HRecur  a  Left) 

The  move  left  operation  in  a  vervec  is  defined  recursively: 
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ULcft  •  ^Kcur  A  Left 


To  shift  the  cursor  of  a  line  to  the  right  is  another  simple  schema: 

LRigh'^  a  StcpForu  a  LOps 

but  the  specifications  of  rightwards  movement  for  horvecs  and  vervecs  are  more 
complicated  as  will  be  seen. 

When  we  apply  the  right  function  to  a  vervec,  we  transform  the  cursor  of  the 
vervec  into  a  two  element  horvec.  The  first  element  of  this  horvec  is  a  vervec  made 
from  the  cursor  sequence  of  the  vervec  and  the  second  element  is  a  blank  line: 

rVR'Shtl  , 

10 

HUINOOUS 

UOps 


0  s’ .9  =  0  s.g 
T  s’ -9  *  <  h  ) 
n  s’ -9  °  n  s.g 
s’. stack  *  s. stack 
uhere 


h: 

doffl 

horvec 

v: 

don 

vervec 

V 

=  make  (1  s. 

9  J 

h  * 

<  V  > 

h  = 

<  blank 

) 

h  = 

0 

i/Right  a  VRightlJ  SctOJ  S 

In  a  horvec,  move  right  is  first  of  all  interpreted  as  a  command  to  move  the  cursor 
onto  the  first  element  of  its  postcursor  sequence: 

HRIghtl  a  (StepForH  a  HOps  11  5 

If,  however,  the  postcursor  sequence  of  the  horvec  is  empty  then  HRightl  is  not 
defined;  in  this  case  a  new  blank  line  type  gblock  is  added  onto  the  end  of  the 
horvec  which  is  then  gone  into: 


ZB 


10 

sUINOOUS 

HOPS 


0  m’.g  >  (0  s.g)  *'  ( s.9> 
1  s* .9  >  <  blank  > 

M  s’ .g  >  <) 
s’ .stack  s  s. stack 


HRj9ht2  a  HddLineJ  SatOJ  S 

Although  at  first  glance  HRightZ  nay  appear  to  be  an  unnatural  operation,  it  is 
this  specification  which  is  the  one  most  used  for  easily  extending  the  length  of 
horvecs.  Altogether  then  we  have: 


HRight  a  (HRightZ  a  HRightl)  a  ((HRecur  a  Right  )J  HNorml 


S«ctioH  IPs  lawrtina  Chfcttri 


Characters  are  inserted  into  lines  iounediately  before  the  cursor,  as  may  be 
expected: 

LInsChar _ _ 

IQ 

SUINOQUS 
LOps 
c:  Char 


p  s'  .g  »  (p  s.g)  "  <  c  > 
1  s’  .9  «  'I  s.g 
et  s’  .9  =  «  s.g 
s’ .stack  -  s. stack 


Characters  inserted  into  horvecs  are  made  into  line  type  gblocks  and  appended  to 
the  precursor  sequence  of  the  horvec  just  as  a  character  is  added  to  a  line: 

InsCharToHor  ^ 

IQ 

HUINOOUS 
HOps 
c:  Char 


p  s’.g  *  (p  5.9)  ■'  <  '"®*‘*(Char]^  <  c  >  )  > 
t  s’ .g  =  t  s.g 
«  s’ .g  *  «  s.g 
s’. stack  3  s. stack 


The  result  of  InsCharToHor  must  be  normalised  to  merge  the  newline  type  gblock 
with  any  that  are  adjacent  to  it  in  the  horvec: 

HInsChar  a  (InsCharToHor  a  HlnsCharRecur  )l  HNorm 

In  a  vervec,  the  action  of  ins_char  is  to  transform  the  cursor  of  the  vervec  into 
a  horvec  consisting  of  the  line  made  from  the  character  and  a  vervec  made  from  the 
cursor  of  the  vervec: 
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InsCharToUer 

ID 

HUIND0U5 
VOps 
c :  Char 


p  s’. 9  ■  p  s-s 
t  s’ .9  =  <  h  > 
n  s’ .g  >  n  s.g 
s’. stack  s  s. stack 
uhere 

I  h:  doni  horvec 


p  h  =  <  "'^•‘^[Char  ]  ^  <c>  )  > 

1  h  =  <  makefQgLQj-i^jt  1  s.g  )  > 
M  h  =  0 


Once  the  horvec  is  created  in  the  vervec  we  go  into  it: 
OlnsChar  a  ( InsCharToOer J  5)  a  OlnsCharRecur 


* 

Sactioii  II;  0«ltto«  ChiractTi 


1 1.1  Delete  Left 


For  •  linci  dcl_lcft  has  a  simple  specification: 

rLDelLaft _ _ 

10 

SUINOQUS 

LOps 


p  s’ . s  =  front  (0  s-s  ) 
1  s’ .g  =  1  S.9 
M  s’ .9  =  n  s.g 
s’. stack  3  s. stack 


For  horvecs  however,  del_left  does  not  have  such  an  easily  intuitive 
specification.  This  complexity  arises  due  to  the  fact  that  within  a  horvec  it  is 
possible  to  delete  the  character  immediately  before  the  cursor  using  delete  left: 

rBackOelChar  _ 

10 

sUINDOUS 

HOPS 


b  e  dam  line 
«  (bind  b )  >  1 

0  s’. 9  =  front  (0  s.g)  ~  <  1  > 
T  s’ .9  =  T  s.g 
«  5’  -9  =  H  s.g 
Mhere 

b  s  last  (B(gblOCK] 

1  fi  make  (front  (bind  b)) 


Obviously  there  will  only  be  a  character  to  delete  if  the  last  element  of  the 
precursor  sequence  of  the  horvec  is  a  line  type  gblock.  There  is  yet,  though,  another 
complication  in  that  even  when  there  is  such  a  gblock,  it  must  contain  at  least  two 
characters  in  order  that  some  characters  are  left  after  the  deletion.  In  the  cases 
where  there  is  only  one  character  in  the  relevant  gblock  the  effect  of  deljeft  in 
the  horvec  is  to  remove  this  gblock  altogether: 
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rBackOclGblock 
10 

sUINOCWS 

HOPS 


b  c  dom  1 i ne 
w  (bind  b)  >  1 
p  s'-s  =  front  (p  s.g) 
1  s' *9  *  1  s.g 
M  s* .9  »  n  S.9 
s’. stack  3  s.stack 
where 

b  £  last  (B[gbL0CK] 


Putting  these  schemas  together  we  have: 

HDelLeft  9  (BackDelChar  y  BackOelGblock  )  a  (HRecur  a  DelLeft  ) 

The  specification  of  delete_left  for  vervecs  is  somewhat  easier: 

UDelLeft  a  (URecur  a  DelLeft  )J  UNorm 

The  normalisation  stage  is  required  for  that  case  where  the  cursor  of  the  vervec  is 
a  horvec  with  two  elements  whose  first  element  is  deleted  during  the  action  of 
BackOelGblock:  such  an  action  would  leave  a  degenerate  horvec  in  the  ver/ec. 

11.2  Delete  Right 

Like  del_left,  del.right  has  a  simple  effect  on  lines: 

rLDelRigHt  _ 

10 

sUINDOUS 

LOps 


9  s’ .9  =  9  s.g 
T  s’ .g  =  <  hd  (n  s.g  )  > 
n  s’  .g  =  tl  (01  s.g ) 
s’. stack  =  s.stack 


The  cursor  of  the  line  is  deleted  and  the  new  cursor  is  the  first  character  that 
appeared  to  the  right  of  the  old  cursor. 

From  the  specification  of  LOelRight  we  notice  that  the  del_rjght  operation  is 
undefined  in  a  line  with  a  null  postcursor  sequence.  When  such  a  situation  occurs  in  a 
line  which  is  the  cursor  gblock  of  a  vervec,  we  replace  the  cursor  sequence  of  the 
offending  line  with  a  space  character  and  assign  this  new  line  to  be  the  cursor  of  the 
vervec: 
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rUOclPartLinc 

10 

sUINDOUS 

i^Ops 


w  ('(  s.g)  >  1 
c  c  dom  1 i ne 
p  s' -s  »  P  s.g 
t  s'.g  »  <  1  > 


M  s'  .g  >  01  s.g 
s' -stack  «  s.stack 
Mhara 

c  4  hd  ('f[GBLOCK] 

1  4  make  (p  c  ''  <  space 


)) 


UDelRight  a  (UOelPartLinei  S)  a  (URecur  a  OelRight) 

When  a  line  with  an  empty  postcursor  sequence  forms  the  cursor  of  a  horvec,  and 
del_right  is  applied  to  the  horvec,  the  result  is  to  delete  the  cursor  sequence  of 
the  line  and  move  right  in  the  horvec; 

HOelPar  tL  i  ne _ _ 

10 

HUINDOUS 

HOps 


e  (1  s.g)  =  1 
c  €  dom  line 
bind  c  e  'T  c 
p  s'.g  *  p  s.g 
t  s' .g  »  <  1  ) 

«  s'.g  ■  01  s.g 
s'. stack  -  s.stack 
uhere 

c  4  hd  (ItGBLOCKJ 
1  4  make  (p  c ) 


DelRightInHorl  4  HDelPartLineJ  HRight 

However,  DelRightInHorl  is  not  defined  if  the  cursor  sequence  of  the  line 
covers  the  whole  line.  To  handle  this  case  we  use  DelRightlnHorZ  which  deletes 
the  entire  line  from  the  horvec  and  moves  right  in  the  horvec  when  possible, 
otherwise  the  original  line  is  replaced  by  a  blank  line: 
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OalUholcLinc 

10 

sUINOOUS 

HOPS 


M  ('T  s.g)  B  1 
c  c  dom  1 j  ne 
bind  c  -  1  c 
0  s’. 9  ■  0  «-9 
M  s.g  >:<>>* 

(1  s’ .9  »  <  blank  >  a 
M  5* .9  z  ( >) 

M  s.g  ^  <  >  •• 

s’ .9  «  hd  (n  s-g )  A 
n  s’  .g  >  tl  (01  s.g  ) ) 
s’. stack  s  s* stack 
Mhere 

c  a  hd  tlf^gLOCK] 


OelRightInHorZ  a  OelUholeLineJ  SetOi  5 
Altogether  we  have 

DelRightInHor  a  DelRightInHorl  v  OelRightInHorZ 
HDelRight  a  DelRightInHor  a  (HRecur  a  DelRight) 


Pervading  ail  of  the  previous  sections  is  the  notion  of  cursor  size  and  how  it 
affects  what  is  actually  perforated  in  the  interface.  This  section  and  the  following  one 
define  those  operations  that  allow  the  displayed  cursor  to  be  expanded  and 
contracted  in  order  to  achieve  precisely  the  function  that  the  user  desires.  Such 
alteration  of  the  cursor  has  no  actiml  influence  on  the  contents  of  a  gblock  and  thus 
there  is  no  need  for  any  post*normalisation  stage. 

What  we  do  use  however  is  the  technique  of  defining  generic  schemas  to  handle 
horevecs,  vervecs  and  lines  in  a  uniform  way  just  as  in  Section  2.  ExpandBack 
extends  the  cursor  sequence  of  the  given  gblock  over  the  last  element  of  the 
precursor  sequence  and  ExpandForu  extends  it  over  the  first  element  of  the 
postcursor  sequence: 

r  ExpandBack  _ 

10 

EUINDQUS 


p  s' .3  =  front  (p  S.9 ) 

1  s’. 9  3  <last  (p  S.3))  ''  (T  s.9) 
n  s' .g  3  «  s.g 
s’. stack  =  s. stack 


rExpandForw 

10 

EUINOOUS 


p  s’. 9  =  p  s.g 

y  s’. 9  =  (1  s.g)  ~  <hd  (w  s.g)) 
«  s’ .9  «  tl  (n  s.g ) 
s’. stack  3  s. stack 


By  supplying  the  relevant  object  class  to  the  above  two  schemas,  we  achieve  the 
desired  specifications: 

LGroupLaft  a  ExpandBack  a  LOps 
VGroupLeft  a  VRecur  a  GroupLeft 

HGroupLaft  a  (ExpandBack  a  HOps)  •  (HRecur  a  GroupLeft) 

LGroupRight  a  ExpandForw  a  LOps 
UGroupRight  a  ORecur  a  GroupRight 

HGroupRjght  a  (ExpandForM  a  HOps)  a  (HRecur  a  GroupRight) 

OGroupUp  a  (ExpandBack  a  UOps )  a  (ORecur  a  GroupUp) 

HGroupUp  a  HRecur  a  GroupUp 

UGroupOoMn  a  (ExpandForn  a  UOps )  a  (URecur  a  GroupDoun  ) 

HGroupDoMn  a  HRecur  a  GroupDoHn 
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section  136  OagoupiM  Bl—witt 


In  a  ntanner  akin  to  that  of  the  previous  section,  we  can  specify  most  ungrouping 
actions  on  horvecs,  vervecs  and  lines  using  only  two  schemas  -  ContractForM  and 
ContractBack  make  the  cursor  sequence  of  the  given  gblock  smaller  by  paring  off  its 
first  and  last  elements  respectively.  Both  schemas  are  defined  only  if  there  are  at 
least  two  elements  in  the  sequence  to  be  trimmed  (since  the  cursor  sequence  of  a  line, 
horvec  or  vervec  must  never  be  empty,  see  section  2): 

fContractForu  _ 

10 

SUIND0U5 


a  (1  s.g)  >  1 

0  s’.g  *  (0  s.g)  ^  <  hd  ("r  s.g)  > 
"t  s’.g  *  tl  s.g ) 

«  s' .g  =  M  s.g 
s’. stack  *  s. stack 


r  ContractBack 
ID 

SUIND0U5 


a  (1  s.g)  >  1 
0  s’.g  -  0  s.g 
1  s’ .g  *  front  (1  s.g ) 
w  s’.g  >:  <  last  (1  s.g)  )  *'  (n  s.g) 
s’. stack  *  s. stack 


Ungrouping  characters  in  a  line  is  easily  specified; 


LUngroupLeft  S  ContractForu  a  LOps 
LUngroupRight  0  ContractBack  a  LOps 


Ungrouping  gblocks  from  the  left  or  the  right  in  a  horvec  is  a  more  complex 
operation:  if  the  operation  makes  the  size  of  the  cursor  sequence  exactly  one,  we 
recursively  "go  in*  to  this  gblock  otherwise  nothing  further  is  done: 


HTrimLaft  0  (ContractForw  a  HOps )J  (S  v  Null) 
HUngroupLsft  0  HTrimLaft  s  (W?ecur  a  UngroupLaft) 

HTrimRight  0  (ContractBack  a  HOps  )J  (5  y  Null) 
HUngroupRight  0  HTrimRight  0  (HRecur  a  UngroupRight ) 


Ungrouping  from  the  top  or  the  bottom  in  a  vervec  is  analogous  to  ungrouping  from 
the  left  or  the  right  in  a  horvec  and  so  we  have; 

UTrimUp  0  (ContractForM  a  UOps  )1  (5  v  Null) 

UUngroupUp  0  UTrimUp  a  (URecur  a  UngroupUp ) 

UTrimOoMn  0  (ContractBack  a  U0ps)f  (5  y  Null) 

UUngroupOoMn  0  UTrimOown  a  (URacur  a  UngroupDown  ) 


37 


Finally  we  specify  those  cases  where  the  direction  of  the  ungrouping  required  is 
inappropriate  to  the  orientation  of  the  object  structure: 

HUngroupOoMn  a  HRecur  a  UngroupOoMn 
HUngroupUp  •  HRccur  a  UngroupUp 
UUngroupLsft  a  URecur  a  UngroupLeft 
UUngroupR i ght  a  URecur  a  UngroupRight 
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Section  14;  Inwrting  GMocki 


As  mentioned  in  section  3,  the  gblock  at  the  top  of  the  stack  of  remembered 
elements  can  be  inserted  either  before  or  above  the  currently  displayed  cursor.  In  all 
cases,  the  insertion  is  followed  at  some  stage  by  'going  in'  to  the  newly  inserted 
gblock. 

Gblocks  can  be  inserted  immediately  before  the  cursor  of  a  line  to  form  a  horvec; 

rInsIntoLine  _ 

HUINDOUS 

ID 


s. 9  c  dom  1 i ne 

s' -9  €  dom  horvec 

p  s'.9  =  <  makeC  p  s.g  )  > 

1  s’.9  =  <  hd  s. stack  > 

ex  s'. 9  =  <  make!  (t  s.g)  "  (o<  s.g)  )  > 

s' -stack  =  tl  s. stack 


The  result  of  the  insertion  is  normalised  and  then  re-entered: 

LInsBefore  A  InsIntoLinel  HNormJ  S 

Inserting  a  gblock  into  a  horvec  at  its  current  cursor  position  is  easily  specified: 

InsIntoHor  _ 

HUINOOUS 

ID 

HOps 


p  s’ -9  =  p  s.g 
T  s'.g  =  <  hd  s. stack  > 

«  s'  -9  =  ('f  s.g )  ^  (o<  s.g ) 
s' -stack  =  tl  s-stack 


HlnsBefore  A  (InsIntoHor  A  (HRecur  a  InsBefore))J  HNormi  5 

Inserting  a  gblock  before  the  cursor  sequence  of  a  vervec  forms  a  horvec  at  that 
position  in  a  manner  similar  to  that  of  InsCharToUer: 


A 


rInsBefIntoVw 
10 

aUINOOUS 

UOps 


p  s’.g  ■  p  s.g 
1  *’ .g  *  <  h  > 

«  s*  .g  >  01  s-g 
s' -stack  •  tl  s-stack 
Mhera 

I  h:  doffl  horvec 


p  h  =  <) 

f  h  s  <  hd  s-stack  > 

01  h  3  <  makeC  '(  s-g  )  > 


UlnsBefore  a  (InsBeflntoUer J  S)  a  (URecur  a  InsBefore) 

Gblocks  are  inserted  above  the  cursor  sequence  of  vervecs  only;  for  horvecs  the 
operation  has  to  be  recursively  applied; 

InsAbovelntoUer  _ 

HUINOOUS 

10 

UOps 


p  s' -g  »  p  s-g 
h  s' -g  =  <  hd  s-stack  > 

01  s'-g  =  ('(  s-g)  ''  («  5-g) 
s' -stack  s  tl  s-stack 


UlnsAbove  a  ( InsAbovalntoDer  a  (VRecur  a  Insflbove))J  UNormJ  S 
HInsflbove  a  HRecur  a  Insflbove 
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Section  1&  Inurtlnt  Wtw  Hum 


r  I  New  lines  can  only  be  inserted  into  vervecs  but  in  two  ways,  either  above  or  below 

I  the  cursor  sequence: 

Blanlffl  ^ 

I 

HUIND0U5 

,  VOps 


P  s’ .9  =  P  S.9 
t  s' • 9  =  <  blank  > 

«  s’. 9  =  (f  s.9)  (m  s.g) 
s’. stack  =  s. stack 


BlankB  _ 
10 

HUINDOUS 

UOps 


P  s’  .9  =  (P  s.g)  ''  (1  s.g) 
1  s’ .g  =  <  blank  > 

(X  s’  .g  =  0.  s.g 
s’. stack  «  s. stack 


Immediately  after  a  new  line  has  been  inserted,  it  is  assumed  that  the  user  wishes 
to  edit  it  and  so  we  ’go  in'  to  the  new  object  at  its  top  left  hand  corner  (0,0): 

UBlankBbove  a  (BlankBJ  SetOJ  5)  a  (VRecur  a  BlankBbove) 

VBlankBeloH  a  (BlankBJ  SetOj  5)  a  (URecur  a  BlankBelow  ) 

For  horvecs,  blank_8bove  and  blank_beloM  are  defined  recursively; 


HBlankBbove  a  HRecur  a  BlankBbove 
HBlankBeloM  a  HRecur  a  BlankBeloH 


section  !fc  OrttlHB  CMoCfci 


In  MaCHO-I,  the  entire  cursor  sequence  of  m  horvec  or  a  vervec  can  be  deleted 
onto  the  current  stack  of  remembered  elements  in  one  operation: 

rOeletcl  . 

10 

HUINOOUS 


M  S.9  e  <  > 

9  s’ .9  *  9  s.g 
1  s’ .9  =  (  hd  (m  s.g )  ) 
n  s’ -9  °  tl  («  s.g ) 

5’ .stack  s  <  makeC  T  s.g  )  >  '^  s. stack 


Oeletel  however  is  not  defined  if  the  postcursor  sequence  of  the  object  gblock 
is  empty  -  in  this  case  the  deletion  is  performed  by  OeleteZ: 

rOeletaZ  _ 

10 

HUINOOUS 


0)  s.g  =  <  > 

9  s’ .g  =  front  (9  s.g) 

1  s’ .g  -  <  last  (9  s.g )  > 

«  s’ .g  »  <  > 

s’. stack  *  <  makeC  1  s.g  )  >  s. stack 


and  so: 

Del  9  Oeletel  v  DeleteZ 

Notice  that  Oel  is  not  defined  if  both  the  pre-  and  post-cursor  sequences  of  the 
object  gblock  are  empty  -  if  it  were  we  would  be  able  to  delete  the  entire  input 
gblock  leaving  nothing  to  be  recorded  as  the  output. 

After  the  deletion  has  been  performed,  we  "go  in'  to  the  top  left  hand  corner  of 
the  new  cursor: 

V)Erase  9  (Oel  a  UOps  )J  TopOervecJ  SetOs  5 

HErase  9  (Oel  a  HOps  )1  TopHorveci  HNorml  SetOl  5 

dn  a  horvec  the  result  of  the  deletion  has  to  be  normalised  in  case  the  deletion 
has  given  rise  to  newly  adjacent  line  type  gblocks.) 

The  full  specifications  of  deletion  in  a  horvec  and  a  vervec  are  thus; 

OOelElament  9  UErase  •  (ORecur  a  DelElement ) 

HDalElement  9  HErase  9  (HRecur  a  DelElement ) 
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Section  17;  Dupllcatfag  CMocIa 


The  duplicate  function  is  defined  only  for  horvecs  end  vervecs,  in  which  case  its 
action  is  to  push  a  gblock  of  the  respective  type  onto  the  top  of  the  given  stack  of 
remembered  elements.  The  pushed  gblock  is  composed  of  the  gbiocks  which  are 
contained  in  the  current  cursor  sequence  of  the  horvec  or  vervec  to  which  the 
operation  is  applied. 

rOup _ , 

10 

cUINDOUS 


s’ .9  =  S.9 

s'. stack  =  <  fliakeC  'f  s.g  )  >  s. stack 


UOuplicate  a  ((Dup  a  UOpsX  TopUervec )  •  (URecur  a  Duplicate) 
HOuplicate  a  ((Dup  a  HQps  )i  TopHorvec  )  a  (HRecur  a  Duplicate) 


StrUon  It;  Undo 


The  undo  function  return*  the  gbloclc  component  of  the  cartMche  to  which  it  is 
applied  but  only  if  this  gblock  is  not  a  line: 

rCUndo  , 

10 

nUINOOUS 


T  s-9  d  dom  1 inc 

s’ .9  *  t  S.9 

s’ . stack  >  s. stack 


After  a  cartouche  is  "undone*  we  "go  in*  to  the  result  at  some  chosen  point  in 
order  perhaps  to  "undo*  another  cartouche  therein.  However,  the  result  of  an  undo 
may  be  a  vervec  which,  if  the  original  cartouche  is  itself  an  element  of  a  vervec,  will 
result  in  a  structure  which  contravenes  the  "no  X  in  X*  rule  of  section  3.  Similarly, 
the  operation  may  result  in  a  horvec  being  created  within  a  horvec  and  so  we  have; 


UUndo  a  (URecur  a  Undo  )J  UNormJ  S 
HUndo  a  (HRecur  a  Undo  )J  HNorml  S 


! 


S«ctloii  !>;  Pull  OpTaticwJ  Spadftotlom 


I 


We  now  present,  in  •  single  unifying  block,  the  full  formal  definitions  of  the  basic 
actions  within  the  MaCHO  Interface: 


COIN  g  LGoIn  y  CGoIn  y  HGoIn  y  UGoIn 
U  GOIN  •goin(s#x>y  )  ^  s’ 


LEFT  g  LLeft  y  HLeft  y  ULeft 
y  LEFT  .  left(  s  )  =  B* 


RIGHT  g  LRigHt  y  HRight  y  URight 
y  RIGHT  .  right(  s  )  =  s’ 

UP  g  HUp  y  UUp 

y  UP  •  up(  s  1  =  s' 


OQUN  g  HOomh  y  UDown 
y  OOUIN  •  downt  s  )  ==  s’ 


INS_CHRR  g  LInsChar  y  HInsChar  y  UlnsChar 
y  INSERT_CHAR  •  ins_char(  s,  c  )  =  s’ 

DEL_LEFT  g  LDelLeft  y  HDelLeft  y  UDelLeft 
y  DELJLEFT  .  del_left(  s  )  =  s’ 

GROUP_LEFT  g  LGroupLeft  y  HGroupLeft  y  VGroupLeft 
y  GROUP J.EFT  .  group_left(  s  )  -  s’ 

GROUP_RIGHT  g  LCroupRight  y  HGroupRight  y  UGroupRight 
y  GROUP_RIGHT  *  group_ri9Ht(  s  )  =  s’ 

GROUP_UP  g  HGroupUp  y  UGroupUp 
y  GROUPJJP  •  group_up(  s  )  *  s’ 


GR0UP_P0UN  g  HGroupOoMn  y  UGroupDoMn 
y  GROUP_POUN  •  group_doHn(  s  )  »  s’ 

UNGROUP_LEFT  g  LUngroupLeft  y  HUngroupLeft  y  VUngroupLeft 
y  UNGROUP_LEFT  •  ur!group_left(  s  )  «  s’ 

UNGROUP_RIGHT  g  LUngroupRight  y  HUngroupRight  y  UUngroupRight 
y  UNGROUP_RIGHT  •  ungroup_r ightt  s  )  *  s’ 

UNGROUP_pOUN  g  HUngroupDoHn  v  UUngroupDoMn 
y  UNGROUP_POUN  •  un9roup_doHn(  s  )  >  s’ 

UNGROUP JJP  g  HUngroupUp  y  ULkigroupUp 
y  UNGROUPJJP  •  ungroupjupC  s  )  >  s’ 


IN5_^B0UE  g  HlnsPbova  y  UlnsPbove 
y  INSJtBOUE  .  ins_gbova(  s  )  *  s’ 


V  HIn*8«for«  v  VInsBcforc 
W  1N5.,0EFOR£  •  insJbcforsC  s  )  «  s* 


M^af^au^Mni  ir  y  ^lank Above 

y  BLANK_ABOyE  •  blank_abave(  s  )  ■  s’ 

V  UBlankBelow 

y  BLANK_BELOU  *  blank_baloM(  s  )  =  s’ 

•  HDalElemant  y  UDelElament 
y  DEL_ELEHENT  •  del_eiefflent(  s  )  >  s’ 


DUPLICATE  a  HOuplicata  y 
y  DUPLICATE  .  duplicata( 


UDupl j  cate 
S  )  a  s’ 


UNDO  a  CUndo  y  HUndo  y  UUndo 
y  UNDO  •  undo (  s  )  *  s* 


I 


I 


Section  20c  Outor  PaflnltioM 


At  the  ffloment,  we  heve  specified  the  operations  of  the  MaCHO  Interface  (section 
19)  without  having  detailed  where  their  inputs,  that  is  s  in  schema  10,  come  from;  we 
shall  do  this  now. 

Recall  from  section  4  that  the  MaCHO  Interface  is  basically  just  a  set  of  BRECTs 
each  one  of  which  has  a  STATE  associated  with  it  which  defines  the  gblock  and  stack 
of  remembered  elements  for  that  window.  Thus,  one  can  select  a  STATE  by  choosing  a 
window  and  taking  the  state  corresponding  to  this  window; 

ChooseState _ , 

EUINDOUS 
s’:  STATE 
b’ :  BRECT 


b*  e  dom  windoMs 
s’  =  MindoHsC  b’  ) 


Given  a  scheme  whereby  we  can  return  a  state  given  a  window,  it  is  natural  to 
define  another  which  given  a  window,  replaces  the  state  corresponding  to  it  with  a 
new  state; 

rReplaceState  _ 

AUINOOUS 
s:  STATE 
b:  BRECT 


b  e  dom  MindoMs 
HindoHs’  2  uindoMs  a  {b  m  b> 

■ 

Now  we  are  just  about  ready  to  specify  in  full  how  each  operation  is  carried  out 
in  the  MaCHO  Interface.  To  do  this  though,  we  must  specify  two  things  -  what 
happens  when  the  chosen  operation  can  be  carried  out  sucessfully  and  the  error 
messages  which  appear  when  it  can’t. 

The  success  of  an  operation  is  determined  by  the  the  success  or  otherwise  of  three 
subtasks; 


•  selection  of  an  input  state 

•  application  of  the  operation  to  this  input  state 

•  recording  of  the  result  of  the  operation  into  the  interface  data  structure 

The  first  and  last  of  these  subtasks  are  ChooseState  and  ReplaceState 
respectively,  the  middle  task  is  defined  in  terms  of  InnerApoly: 

rInnerApply 

EUINDOUS 

ID 

FUN 


B  e  dom  f 
s’*  f(  s  ) 


47 


We  will  put  these  three  ttefct  together  using  as  an  example  the  ’move  cursor  left' 
function. 

The  middle  task  is  specified  by  a  schema  which  given  any  input  state  returns  the 
state  which  is  the  result  of  moving  the  cursor  left  in  this  state: 

LeftOK  •  Innerf^pplx  a  Left 

The  successful  application  of  ’move  cursor  left*  on  a  state  extracted  from  a 
window  in  the  interface  is  thus  described  by: 

OLeft  e  ChooscStateJ  LcftOKj  RepleceState 

Several  other  operations  that  can  be  performed  by  the  MaCHO  Interface  are 
specified  in  a  manner  similar  to  that  above: 

UpOK  a  InnerApply  a  Up 

OUp  a  ChooseStateJ  UpOKJ  ReplaceState 

DoMnOK  a  InnerSpply  a  Down 

□Down  a  ChooseStateJ  OownOKJ  ReplaceState 

OelLeftOK  a  InnerApply  a  DelLeft 

□OelLeft  a  ChooseStateJ  DelLeftOKJ  ReplaceState 

GroupLeftOK  a  Innerflpply  a  GroupLeft 

□GroupLeft  a  ChooseStateJ  GroupLeftOKJ  ReplaceState 

GroupRightOK  a  Inner Apply  a  GroupRight 

QGroupRight  a  ChooseStateJ  GroupR IghtOKj  ReplaceState 

GroupUpQK  a  InnerApply  a  GroupUp 

QGroupUp  a  ChooseStateJ  GroupUpOKJ  ReplaceState 

GroupOownQK  a  InnerApply  a  GroupDown 

OGroupDown  a  ChooseStateJ  GroupOownOKJ  ReplaceState 

UngroupLeftOK  a  InnerApply  a  UngroupLeft 
□UngroupLeft  a  ChooseStateJ  UngroupLeftOKJ  ReplaceState 

UngroupRightOK  a  InnerApply  a  UngroupRight 
OUngroupRight  a  ChooseStateJ  UngroupRightOKJ  ReplaceState 

UngroupUpOK  a  InnerApply  a  UngroupUp 

□UngroupUp  a  ChooseStateJ  UngroupUpOKJ  ReplaceState 

UngroupDoMnOK  a  InnerApply  a  UngroupDown 
OUngroupOoMn  a  ChooseStateJ  UngroupDoMnOKJ  ReplaceState 

UndoOK  a  InnerApply  a  Undo 

□Undo  a  ChooseStateJ  UndoOKJ  ReplaceState 

Having  (pacified  the  successful  cases  above,  we  now  turn  out  attention  to  the  error 
cases. 

When  an  error  occurs,  an  error  report  is  signalled  to  the  user.  The  invocation  of 
such  a  message  in  no  way  affects  the  contents  of  the.  windows  in  the  interface: 


REPORT  a  seq  Char 


r Error  ___ 

HUINDOUS 

10 

r!:  REPORT 


FailLcft  *  [  Error  |  r!  >  "Cannot  Hove  Left*  1 
FailUp  *  [  Error  |  r!  >  "Cannot  Hove  Up"  1 
FailDoMn  a  [  Error  |  r!  «  "Cannot  Hove  Down"  ] 

FailDel  a  t  Error  j  r!  >  "Cannot  Delete  Object*  1 
Fai  IGrr'jpLeft  a  [  Error  |  r!  »  "Cannot  Group  Left"  1 
Fai IGroupRight  a  [  Error  |  r!  -  "Cannot  Group  Right"  ] 

FailGroupUp  a  t  Error  |  r!  >  "Cannot  Group  Up"  1 
Fai IGroupOoMn  a  C  Error  |  r!  »  "Cannot  Croup  Doun"  1 
Fai lUngroupLeft  a  C  Error  I  r!  =  "Cannot  Ungroup  Left"  ] 

Fai lUngroupRight  a  C  Error  |  r!  *  "Cannot  Ungroup  Right"  ] 

Fai lUngroupUp  a  [  Error  |  r!  «  "Cannot  Ungroup  Up*  1 
Fai lUngroupDoMn  a  I  Error  |  r!  -  "Cannot  Ungroup  Doun*  1 
FailUndo  a  t  Error  |  r!  ^  "Cannot  Undo  -  not  a  cartouche?"  1 

By  combining  the  error  schemas  above  with  their  relevant  functions  we  can  specify 
completely  most  of  the  operations  of  the  MaCHO  Interface  -  raising  an  exception  only 
when  the  attempted  operation  fails: 

□uterLeft  a  FailLeft  a  QLeft 
□uterUp  a  FailUp  a  QUp 
Outer  Down  a  FailDoMn  a  ODoMn 
OuterDelLeft  a  FailDel  a  ODelLeft 
Outer GroupLeft  a  FailGroupLeft  a  OGroupLeft 
OuterGroupRight  a  Fai IGroupRight  a  OGroupRight 
OuterGroupUp  a  FailGroupUp  a  OGroupUp 
OuterGroupDown  a  Fai IGroupDown  a  OGroupUoun 
OuterUngroupLeft  a  Fai lUngroupLeft  a  OUngroupLeft 
OuterUngroupRight  a  Fai lUngroupRight  a  OUngroupRight 
Outer UngroupUp  a  FailUngroupUp  a  QUngroupUp 
OuterUngroupDoMn  a  Fai lUngroupDown  a  DUngroupDoMn 
Outer Undo  a  FailUndo  a  OUndo 

We  now  come  to  define  the  'outer*  versions  of  those  functions  from  section  4  whose 
appropriate  action  when  the  inner  application  is  undefined  is  n^  to  immediately  flag 
an  error  (as  the  preceding  defintions  of  this  section  have  done). 

For  instance,  consider  the  case  where  the  outer  gblock  is  a  cartouche  and  the  user 
wishes  to  duplicate  this  object.  Then,  since  duplicate  is  defined  only  for  horvecs  and 
vervecs,  if  we  followed  the  pattern  given  so  far  in  this  section  we  would  signal  an 
error  ’cannot  duplicate*  when  it  would  appear  that  the  requested  operation  is 
entirely  reasonable.  Thus  we  define  OOup: 

_0Dup 
10 

EUIN00U5 


*’ -9  *  S-S 

s’. stack  *  <  s.g  >  ~  s. stack 

■ 


and  then: 

DuplicataOK  9  ODup  a  (Inner Apply  a  Duplicate) 
□Duplicate  9  ChooseStataJ  OuplicateOKJ  ReplaceState 
□uterOupl icate  9  ODuplicate 
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A  similar  line  of  argument  leads  us  to  define  ODel  which  deletes  the  outer  gblock 
onto  the  stack  of  remembered  elements  and  sets  the  outer  gblock  to  be  a  blank  line: 

pOD.1 - , 

10 

HUINOOhtS 


s'. 9  -  blank 

.s’ -stack  »  <  S.9  >  ''  s.stack 

-  . .  . - .  .  t 

DelElemantOK  A  OOal  a  (InnarApply  a  DalElaaant ) 
□OelElcment  A  ChoosaStataJ  DalElanantOKk  RaplacaStata 
□uterOalElamant  A  OOalElanant 

For  inserting  elements  above  the  outer  gblock  we  define  OlnsA: 


_QInsfl 


■ 

s’.9  c  dom  vervec 

9  s' .9  = 

<  > 

1  s’.g  = 

<  hd  (s.stack)  > 

M  s’ .9  = 

<  s.9  > 

s’ .stack 

»  tl  (s.stack  ) 

.  1  1 

and  for  inserting  elements  alongside  the  outer  gblock  we  define  OInsB: 

_0InsB  _ 

10 

HUINDOUS 


s’ .9  €  dam  horvec 

9  s’  .9  =  0 

t  s’.9  s  <  hd  (s.stack)  > 

«  s’  .9  31  (  s.9  > 

s’. stack  s  tl  (s.stack) 


After  inserting  a  gblock  at  the  outermost  level  we  normalise  the  results  of  the 
insertion  then  "go  in’  to  their  cursor  -  just  as  is  done  when  inserting  into  a  horvec 
or  a  vervec: 

InsBbovaOK  A  (OInsPJ  VNormJ  S)  a  (Innarflpply  a  InsBbove ) 

InsBaforaOK  A  (OInsBJ  HNormi  5)  a  (InnarA^ly  a  InsBefore) 

All  inserts  however  are  only  pouible  if  (a)  there  is  something  to  insert  and  (b)  if 
there  is  room  to  insert  the  object  into  the  outer  gblock  (recall  the  maximum 
dimensions  for  gblocks  specified  in  section  5).  We  can  define  two  error  schemas  to 
describe  what  messages  appear  when  these  conditions  are  violated: 

NoRooffl  A  [  Error  I  r!  *  "No  Room  to  Insert  Object"  1 

EmptyStack  A  [  Error  |  s.stack  >  <>  a 

r!  w  "No  Remembered  Elements"  1 

InsError  A  NoRoom  a  EmptyStack 

Then  we  have: 
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OInsAbovc  A  ChooscStatcJ  InsAboveOKJ  RcplaceState 
OuterInsAbove  A  InsError  •  OInsAbove 

OlnsBefore  •  ChooseStatcJ  InsBaforaOKi  ReplaceState 
Outer InsBefora  A  InsError  a  OlnsBefore 

We  can  also,  of  course,  insert  a  blank  line  type  gblock  either  above  or  below  the 
outer  gblock: 

rOBlankB _ _ 

10 

BUINDOUS 


s' -9  £  dom  vervec 
B  s’ .9  =  <  S.9  > 
t  s’ .g  =  <  blank  > 
«  s’ .g  =  <  > 
s’ -stack  =  s. stack 


rOBlankA  . 

ID 

HUINOOUS 


s’, 9  €  dom  vervec 
B  s’, 9  =  <> 
t  s’.g  =  <  blank  > 
n  s’ .g  s  <  s.g  > 
s’. stack  -  s. stack 


BlankAboveOK  A  (OBlankAJ  SetOJ  S)  a  (InnerApply  a  BlankAbove) 
BlankBelowOK  a  (OBlankBJ  SetOJ  S)  a  (InnerApply  a  BlankBelow) 
OBlankAbove  a  ChooseStateJ  BlankAboveOKJ  ReplaceState 
OBlankBeloM  a  ChooseStateJ  BlankBelowOKi  ReplaceState 

OuterBlankAbove  a  NoRoom  a  OBlankAbove 
OuterBlankBelow  a  NoRoom  a  OBlankBeloM 

A  request  to  move  the  cursor  right  at  the  outer  level  creates  a  horvec  whose  first 
element  is  the  original  outer  gblock  and  whose  second  element  is  a  blank  line; 

rOToHor _ , 

10 

EUINDOUS 


s’.g  c  dom  horvec 
B  s’ .g  >  <  s.g  > 

'1  s’  >9  *  <  blank  ) 
«  s’ .g  =  < ) 
s’ .stack  B  s. stack 


This  extra  blank  line  can  only  be  inserted  if  there  is  room  for  it  and  so  we  have: 

RightOK  a  (OToHorJ  HNorm)  a  (InnerApply  a  Right) 

DRight  a  ChooseStateJ  RightOKJ  ReplaceState 
OuterRight  a  NoRoom  a  ORight 


Typing  a  character  at  the  outer  level  also  forms  a  horvec  but  again  only  if  there 


rInsChar  Apply 
10 

EUIND0U5 
c :  Char 


(s«  c)  c  dam  ins_char 
s’  =  ins_char(  s.  c  ) 


rOInsC _ 

ID 

HUINOOUS 
c :  Char 


s’ • 9  €  dom  horvec 
p  s’ -9  =  <  makeC  <  c  >  )  > 
1  s’ -9  =  <  S.9  ) 

«  s’ . 9  =  ( > 
s’ -stack  =  s. stack 


InsCharOK  a  OlnsC  a  (InnerApply  a  InsCharApply  ) 

□InsChar  a  ChooseStateJ  InsCharOKJ  ReplaceState 
□uterInsChar  a  NoPoom  a  OInsChar 

For  0uterDelRi9ht  we  need  to  lake  into  account  the  case  when  the  outer  gblock 
is  a  line  with  a  null  postcursor  sequence  since  del^T'Sht  is  not  defined  for  this  line: 

ODelR _ _ 

10 

HUINOOUS 

LOps 


p  s  -9  =  B  s-g 
1  s’ -3  =  <  space  ) 
w  s’ .9  =  <  > 
s’. stack  =  s. stack 


DelRl9ht0K  a  OOelR  a  (Inner Apply  a  DelRi9ht  ) 
00elRi9ht  a  ChooseStateJ  DelRi9ht0KJ  ReplaceState 
Outer InsChar  a  FailOel  a  OOelR i9ht 
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Abstract 

This  document  describes  the  basic  editor  part  of  the  user  interface  for  the 
SMITE  secure  computer  architecture  using  the  mathematical  notation  known  as  Z. 
Operations  that  are  available  to  the  user,  and  their  effects  on  the  screen 
display,  are  specified  in  conjunction  with  descriptions  of  the  auxiliary 
functions  and  data  structures  necessary  to  support  them.  This  specification 
will  be  used  to  implement  a  powerful  yet  trustworthy  interface  for  the 
initiation  and  control  of  security  related  transactions. 
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